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The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
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A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 
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earned patent term adjustment. See 37 CFR 1.704(b). 
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DETAILED ACTION 



Response to Arguments 



1. Applicant's arguments filed 17 October 2002 have been fully considered but they are not 
persuasive, with regards to the § 112 rejections. The Applicant asserts that applicants may act as 
their own lexicographers in defining a term so long as the meaning is clearly provided in the 
specification, and is not repugnant to the term's common usage. The examiner agrees with this 
assertion; however, in this case, the examiner contends that the term is not clearly provided in the 
specification, and, even if it were, the term is repugnant to the term's common usage. Applicant 
states that a hierarchical network is defined as a network in which network address formats have 
a hierarchical structure and points to page 4, line 35 through page 5, line 6 of the specification as 
evidence of this definition. The examiner failed to find support for this definition in the 
aforementioned parts of the specification. As such, the examiner submits that the term's meaning 
is not clearly provided in the specification. In addition, even if such a definition of a hierarchical 
network were given in the specification, calling an IPv4 network non-hierarchical is repugnant to 
the term's common usage. An IPv4 address contains a network block and a host block. This 
format is hierarchical in structure with the hierarchy containing two levels, namely the network 
and the host. For example, Krishnan refers to an address containing a network block and a host 
block as hierarchical (col. 5 lines 38-53). Thus, the examiner contends that referring to an IPv4 
address as non-hierarchical is repugnant to the term's common usage. 

2. Applicant's arguments with respect to claims 1-12, with respect to the § 103 rejections, 
have been considered but are moot in view of the new ground(s) of rejection. 
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Claim Rejections - 35 USC § 112 

3. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

4. Claims 1-12 are rejected under 35 U.S.C. 1 12 5 first paragraph, as containing subject 
matter which was not described in the specification in such a way as to enable one skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and/or use the 
invention. Prior art rejections will be made according to the examiner's best interpretation at the 
time of examination. 

5. Regarding claims 1-12, the applicant stated in the specification that the invention's 
intended use is as a transition between IPv4 and IPv6 networks. This statement allows for 
confusion because in the claims the applicant specifies the invention's intended use is as a 
transition between hierarchical and non-hierarchical networks. It is assumed that the IPv4 
network is the claimed non-hierarchical network; however, in a broad context, an IPv4 network 
could be viewed as a hierarchical network containing two levels (one level being the inter-router 
network and the other level being the host network). Since an IPv4 network could be viewed as 
hierarchical, there is confusion between the specification and the claims, and thus the claims are 
not enabling. For purposes of this office action, a non-hierarchical network is interpreted as an 
IPv4 network. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 




Application/Control Number: 10/075,430 Page 4 

Art Unit: 2665 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

7. Claims 1 and 7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Krishnan 
(USPN 6, 157,950) in view of Callon (Callon, R. "Routing Aspects of IPv6 Transition." 
Networking Working Group RFC 2185. September 1997) in further view of Gilligan (Gilligan, 
R. "Transition Mechanisms for IPv6 Hosts and Routers." Networking Working Group RFC 
1933. April 1996.). 

8. Regarding claims 1 and 7, Krishnan discloses that the internet is a "heterogeneous 
collection of many computer networks interconnected by devices, such as 'bridges' and 'routers' 
that enable computers on one network to communicate with computers on other networks" (col. 
3 lines 52-57). The hierarchical structure of an IP address enables an IP datagram (IP packet) to 
be routed from one network to another network, even if the sending node does not know the path 
to the destination node. Each IP address is hierarchical because it consists of two main parts: the 
network ID and the node ID. The network ID distinguishes one network from the plurality of 
networks in the inter-network. The node ID distinguishes one node from the plurality of other 
nodes within a network (col. 5 line 37- col. 4 line 27 and col. 5 lines 51-67). Within a network, 
all communication between nodes is done solely on the basis of the node ID. The network ID is 
used when a node in one network communicates with a node on a separate network. In this 
scenario, the source node routes the packet to a "gateway node" which connects the network to 
the inter-network. The gateway node uses the network ID to determine in which network the 
destination node is located and to forward the packet to the gateway node of the destination 
network. The destination gateway node then forwards the packet to the node with the node ID 
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contained in the destination address. Thus Krishnan discloses assigning a network a hierarchy 
number (network ID) that corresponds to a hierarchy number (network ID) in the hierarchical 
network (internet or inter-network); using the virtual hierarchy number of a packet to be relayed 
at a router (gateway node) located at an entrance from the network to the hierarchical network 
when the packet is to be relayed between networks via the hierarchical network; performing a 
hierarchical routing control by the virtual hierarchy number within the hierarchical network; and 
ignoring the virtual hierarchy number of the packet to be relayed at a router located at an exit 
from the hierarchical network to the destination network (col. 3 lines 52-57 and Fig. 3. and col. 5 
lines 37-col. 4 line 27). Krishnan possibly does not disclose attaching the virtual hierarchy 
number to a packet to be relayed at a router located at an entrance from a network to the 
hierarchical network when the packet is to be relayed between networks via the hierarchical 
network and removing the virtual hierarchy number from the packet to be relayed at a router 
located at an exit from the hierarchical network to the destination network. Callon and Gilligan 
both teach implementing a mixed environment of IPv6 and IPv4 networks where an IPv4 
network is taken to be non-hierarchical and an IPv6 network is taken to be hierarchical. IPv6 
differs greatly from IPv4 with regards to the size of IP addresses. IPv6 addresses are 128 bits and 
IPv4 addresses are 32 bits (Gilligan: page 3, section 2). In order to operate IPv6 and IPv4 
networks side-by-side, an addressing method has been developed dubbed IPv4-Compatible IPv6 
addressing in which IPv4 addresses are incorporated into IPv6 addresses (page 3, section 2 and 
page 4, section 3.1). With this method, gateway nodes run "dual IP layer" in which the gateway 
node is capable of supporting both IPv4 and IPv6 datagrams. By packing an IPv4 address as an 
IPv6 address using an IPv4-Compatible IPv6 address (address which incorporates a valid IPv4 
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address into the lower 32 bits of an IPv6 address) or extracting an IPv4 address from an IPv4- 
Compatible IPv6 address, the gateway is able to convert IPv4 packet addresses to IPv6 addresses 
and vice versa (Gilligan: page 15, section 4.3, page 2 section 1.2 "Types of IPv6 Addresses" and 
Callon: page 1, section 2 and page 3 section 3.1). It should be noted that IPv6 addresses follow 
the IP address method of being hierarchical by having a computer ID and network ID. An IPv4- 
Compatible IPv6 address is distinct from other IPv6 addresses because it has the network IDs 
zeroed and the IPv4 address placed in the computer ID section. Thus, the IPv4-Compatible IPv6 
address can be viewed as having a network ID of 0. As such, Callon and Gilligan disclose 
attaching the virtual hierarchy number (the IPv6 network ID section in an IPv4-Compatible IPv6 
address) to a packet to be relayed at a router located at an entrance from an IPv4 network to an 
IPv6 inter-network when the packet is to be relayed between IPv4 networks via the IPv6 inter- 
network and removing the virtual hierarchy number (extracting the IPv4 address) from the 
packet to be relayed at a router located at an exit from the IPv6 inter-network to the IPv4 
network. It would have been obvious to one of ordinary skill in the art to attach a virtual 
hierarchy number to a packet to be relayed at a router located at an entrance from an IPv4 
network to an IPv6 inter-network when the packet is to be relayed between IPv4 networks via the 
IPv6 inter-network and to remove the virtual hierarchy number from the packet to be relayed at a 
router located at an exit from the IPv6 inter-network to the IPv4 network in order to allow an 
IPv4 packet to be transported over an IPv6 inter-network. 

9. Regarding claims 2 and 8, referring to claims 1 and 7, Gilligan and Callon disclose 
having an address of the IPv4 network be accommodated in an interface identification 
information block (computer ID) of an address format of the IPv6 network, and the virtual 
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hierarchy number be accommodated in a hierarchy information block of the address format of 
the IPv6 network for conventional packet relaying defined in the IPv6 network and transmitting 
routing information (Gilligan: page 15, section 4.3, page 2 section 1.2 "Types of IPv6 
Addresses" and Gallon: page 1, section 2 and page 3 section 3.1) where the virtual hierarchy 
number is 0. Gilligan and Callon do this in order to make IPv4 addresses compatible with IPv6 
addresses. 

10. Regarding claims 3 and 9, referring to claims 2 and 8, Gilligan discloses that in a gateway 
node two routing tables are kept, one for the IPv6 address and one for the IPv4 address (Gilligan: 
page 5 sec. 3.2.1). This is done so that the gateway node can keep an accurate routing table of 
IPv6 addresses and IPv4 addresses. However, it is obvious that the router must be able to 
transition between both tables in order to be capable of handling IPv4-Compatible IPv6 
addresses. An IPv4-Compatible IPv6 address is recognizable as an IPv4-Compatible IPv6 
address through its network ID block which specifies the network to which the packet belongs. 
The network ID indicates an IPv4 or IPv6 compatible network, for instance a network ID of 0 
indicates an IPv4 network. In order to make IPv6 routing decisions, the router only needs to use 
the network ID (hierarchical information block) of the IPv4-Compatible IPv6 address, but in 
order to transition from IPv6 to IPv4, the router must be able to recognize the packet as an IPv4- 
Compatible IPv6 address through the network ID (hierarchical information block) and then use 
the IPv4 address stored in the computer information block (interface identification block). Thus, 
as broadly interpreted, Gilligan discloses having each router of the IPv6 network have a routing 
table that performs a routing search by using only the hierarchical information block as a key 
(routing IPv6 packets based on network ID), and a conventional routing table that performs 
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routing search by using the hierarchical information block hierarchical information and the 
interface identification information block as keys (IPv4 conversion, identifying the packet as one 
containing an IPv4 address and routing according to that address) (Gilligan: page 5 sec. 3.2.1). It 
would have been obvious to one of ordinary skill in the art to have a router of the IPv6 network 
have a routing table that performs a routing search by using only the hierarchical information 
block as a key, and a conventional routing table that performs routing search by using the 
hierarchical information block hierarchical information and the interface identification 
information block as keys in order to allow the router to route IPv6 packets and transition 
between IPv6 and IPv4 packets. 

11. Regarding claims 4 and 10, referring to claims 3 and 9, Gilligan discloses that in a 
gateway node two routing tables are kept, one for the IPv6 address and one for the IPv4 address 
(Gilligan: page 5 sec. 3.2.1). This is done so that the gateway node can keep an accurate routing 
table of IPv6 addresses and IPv4 addresses. However, it is obvious that the router must be able to 
transition between both tables in order to be capable of handling IPv4-Compatible IPv6 
addresses. An IPv4-Compatible IPv6 address is recognizable as an IPv4-Compatible IPv6 
address through its network ID block which specifies the network to which the packet belongs. 
The network indicates an IPv4 or IPv6 compatible network, for instance a network ID of 0 
indicates an IPv4 network. In order to make IPv6 routing decisions, the router only needs to use 
the network ID (hierarchical information block) of the IPv4-Compatible IPv6 address, but in 
order to transition from IPv6 to IPv4, the router must be able to recognize the packet as an IPv4- 
Compatible IPv6 address through the network ID (hierarchical information block) and then use 
the IPv4 address stored in the computer information block (interface identification block). Thus, 
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Gilligan discloses having each router of the hierarchical network use the hierarchical routing 
table when relaying a packet between the hierarchical network and another hierarchical network 
(Gilligan: page 5 sec. 3.2.1). It would have been obvious to one of ordinary skill in the art to 
have each router of the hierarchical network use the hierarchical routing table when relaying a 
packet between the hierarchical network and another hierarchical network in order to allow the 
router to route IPv6 packets through the inter-network. 

12. Regarding claims 5 and 1 1, referring to claims 3 and 9, Gilligan discloses that in a 
gateway node two routing tables are kept, one for the IPv6 address and one for the IPv4 address 
(Gilligan: page 5 sec. 3.2.1). This is done so that the gateway node can keep an accurate routing 
table of IPv6 addresses and IPv4 addresses. However, it is obvious that the router must be able to 
transition between both tables in order to be capable of handling IPv4-Compatible IPv6 
addresses. An IPv4-Compatible IPv6 address is recognizable as an IPv4-Compatible IPv6 
address through its network ID block which specifies the network to which the packet belongs. 
The network indicates an IPv4 or IPv6 compatible network, for instance a network ID of 0 
indicates an IPv4 network. In order to make IPv6 routing decisions, the router only needs to use 
the network ID (hierarchical information block) of the IPv4-Compatible IPv6 address, but in 
order to transition from IPv6 to IPv4, the router must be able to recognize the packet as an IPv4- 
Compatible IPv6 address through the network ID (hierarchical information block) and then use 
the IPv4 address stored in the computer information block (interface identification block). Thus, 
as broadly interpreted, Gilligan discloses having each router of the hierarchical network use the 
conventional routing table when relaying a packet from the hierarchical network to the non- 
hierarchical network, and from the non-hierarchical network to the hierarchical network 
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(Gilligan: page 5 sec. 3.2.1). It would have been obvious to one of ordinary skill in the art to 
have each router of the hierarchical network use the conventional routing table when relaying a 
packet from the hierarchical network to the non-hierarchical network, and from the non- 
hierarchical network to the hierarchical network in order to allow the router to transition between 
IPv6 and IPv4 packets. 

13. Claims 6 and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable over Krishnan 
(USPN 6,157,950) in view of Callon (Callon, R. "Routing Aspects of IPv6 Transition. 55 
Networking Working Group RFC 2185. September 1997) in further view of Gilligan (Gilligan, 
R. 'Transition Mechanisms for IPv6 Hosts and Routers." Networking Working Group RFC 
1933. April 1996.) applied to claims 5 and 1 1 above, and further in view of Miki (USPN 
6,046,999). 

14. Regarding claims 6 and 12, referring to claims 5 and 11, Krishnan in view of Callon in 
further view of Gilligan possibly does not disclose that the router located at a boundary of the 
IPv4 network and the IPv6 network recognizes a packet relay from the IPv4 network to the IPv6 
network, and from the IPv6 network to the IPv4 network, by using a receiving interface name 
and a transmission interface name when relaying the packet. Miki discloses a router that uses a 
"switch port number. . .which is set for each of various interfaces such as the ATM interface, the 
IP-support frame relay interface, etc. The IP controller... recognizes the port with the switch port 
number." (col. 7 lines 52-54). Miki's router, which recognizes the format of data of an 
information packet based upon the port at which it arrived, has the benefit of "providing] a 
router apparatus which can support various types of communications." (col. 2 lines 59-61) As 
broadly defined, the serial number, as described above, is interpreted as an "interface name." 
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Thus it would have been obvious to one of ordinary skill in the art of routers at the time of the 
invention to have a router located at a boundary of the IPv4 network and the IPv6 network 
recognize a packet relay from the IPv4 network to the IPv6 network, and from the IPv6 network 
to the IPv4 network, by using a receiving interface name and a transmission interface name when 
relaying the packet in order to allow the "mixed environment" router to "support various types of 
communications" by recognizing from the port at which the data arrived whether it was an IPv6 
type packet to be converted to an IPv4 format or vice versa. 

Conclusion 

15. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. Rekhter Y. "An Architecture for IPv6 Unicast Address Allocation." Networking 
Working Group RFC 1887. December 1995. Malkin G. "RIPing for IPv6." Networking Working 
Group RFC 2080. January 1997. Hinden R. "IP Version 6 Addressing Architecture." Networking 
Working Group RFC 2373. July 1998. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Daniel J. Ryman whose telephone number is (703)305-6970. The 
examiner can normally be reached on Mon.-Fri. 7:00-4:00 with every other Friday off. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Huy Vu can be reached on (703)308-6602. The fax phone numbers for the 
organization where this application or proceeding is assigned are (703)308-6743 for regular 
communications and (703)308-9051 for After Final communications. 

Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is (703)305-3900. 
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Daniel J. Ryman 
November 1 , 2002 



Daniel J. Ryman 
Examiner 
Art Unit 2665 
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